> Je ne sais pas si c'est vraiment un killer app. C'est très peu visible
> pour un usager normale. Beaucoup de la fonctionnalité peut-être émulé

Voilà la raison du « au sens large ». Pas directement, clairement, mais
pourra devenir la base de plein d'applications.

> >Partir de quelque chose qui fonctionne et l'améliorer OU envisager la
> >perfection et ne jamais rien foutre?
> Je ne crois pas que c'est ça que les gens du noyau disent. Ton argument
> s'applique au mon Windows, on le fait à moitier mais au moins on le
> fait, on règlera les problèmes de structure plus tard.

Il ne s'agirait pas je pense de « faire à moitié » si le but ultime
consiste à se conformer à la structure du noyau. Je ne m'attends pas
(et je ne veux surtout pas m'attendre) à ce que lorsque ReiserFS4
entrera dans le noyau, que tout marchera parfaitement, de manière
élégante, et que les oiseaux vont chanter.

Là le mieux qui puisse arriver: Namesys à chaque dot-release du noyau
doit recommencer ses patch pour se synchroniser avec la cible mouvante
du noyau. Perte de temps et gossage, pendant qu'on pourrait déjà avoir
1000 usagers qui roulent ReiserFS4 et le testent à mourir sur plein de
hardware différent, 10 kernel developers qui savent que lorsqu'ils
changent le scheduler ils doivent aller voir le code de ReiserFS, 10
autres développeurs qui savent qu'ils doivent vérifier leurs patch
SELinux, etc, etc, etc.

> Il existe des FS avec attributs étendus déjà dans le noyau (ext3fs, xfs,
> jfs, etc.) et il existe un système de sécurité modulaire. De plus, il
> commence à y avoir un mouvement vers des drivers FS userspace (FUSE). Il
> y a beaucoup de développement de ce côté. ReiserFS vient s'insérer dans
> tout ça en faisant tout à sa manière... gossant. Pas que c'est mal...
> mais je vois le point de vue des développeurs Linux.

Jusqu'à preuve du contraire, ReiserFS4 peut se lier au kernel existant
sans trop briser d'affaires. Je ne dis pas qu'à moyen terme tous ces
systèmes ne devront pas être unifiés; je dis que d'essayer d'obtenir une
patch parfaite d'un coup qui s'intègre élégamment à la structure du
kernel c'est comme de te demander de construire un climatiseur pour
mettre dans une automobile en 1 étape « cloc! » pendant que le modèle de
l'automobile change toutes les 2 semaines...

> >Partir de quelque chose de monolithique donc isolé donc sans incidence
> Ça n'évite pas le problème. Lorsqu'on voudra modifier le noyau et
> enlever l'isolement, on recontrera des problèmes, aussi bien le faire
> tout-de-suite.

Je ne dis pas que ça règle tout seul les problèmes qui doivent être
résolus. Sauf qu'on a ainsi l'occasion de les régler 1 par 1, et voir
l'incidence tout de suite, avec une base d'usagers, des kernel
developers qui ont déjà vu le code.

Peux-tu me dire sans rire que tu peux planifier exactement toutes les
opérations à accomplir pour rénover ta salle de bains, les écrire sur un
papier, donner le papier à un robot et t'en aller? mais non! y'a plein
de cossins auxquels t'auras pas pensé, et qui vont te sauter dans la
face au moment opportun.

Est-ce que tu te sauves de l'énergie à tout planifier d'avance? non.
Avoir une idée d'où tu pars, de l'ordre dans lequel tu effectues les
travaux, oui ça aide; avec trop de détails tu risques même de te péter
la gueule en revenant voir ton robot jammé dans la porte avec tes portes
de douche parce que tu n'avais pas pensé que l'été le bois enfle.

On coupe les tuiles quand vient le temps de faire le plancher.

> Est-ce que tu serais d'accord d'une patch qui ré-implément IP par dessus
> TCP? Même si ça apporte plein de nouvelles fonctionnalités tel que la
> sécurité? Tu es d'accord avec moi que ce serait mal. Pourtant c'est ce

Si la patch ne brise rien, non ça ne gagnerait pas de prix d'élégance.
Mais sachant qu'à moyen terme les nouvelles fonctionnalité d'IP seraient
intégrées au stack IP existant et que tout le long du processus de
migration on pourrait tester si le nouveau stack IP est pas brisé, moi
je vote OUI.